A number of problems are encountered when a computing device, such as a portable computer or a Personal Digital Assistant (PDA), attempts to communicate over the Internet with one or more systems within an enterprise. Various network configurations impede initiating communication via the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP) from a computing device outside the enterprise to a system within the enterprise. Similarly, it is also difficult to initiate communication from systems within enterprise networks to external portable devices.
A system within an enterprise is typically protected by a firewall or a Network Address Translator (NAT) (or both). Many network address translators do not support addressing for communication initiated from outside the network to a system within the network. Most firewalls are configured to prevent communications initiated from machines outside the network to protect systems within the enterprise network from intruders. While most systems within the enterprise network can initiate communication to systems outside the enterprise, they are typically unable to receive communications initiated from outside machines. More often than not, these outside requests are dropped by the firewall if the internal machines are at all publicly addressable.
In addition, the service providers for the portable devices that communicate over a wireless network often do not allow communication initiated from outside their network to devices on their network. Mobility of the user may also mean that the portable device has a dynamic IP address. These devices would find it difficult to receive communication initiations from other systems either because their IP address is unknown to other systems or the service provider prevents incoming communications.
Users who are away from their enterprise need to connect to systems within their enterprise network in a secure fashion. Virtual Private Networks (VPNs) allow communication between two systems on the Internet, but utilize a significant amount of resources on the portable devices. Portable devices, however, typically have resource constraints that make a lighter weight solution desirable. Dial-in software allows a portable device to communicate with systems within an enterprise network, but dial-in software requires a telephone line and does not take advantage of the increasing availability of Internet access and applications. Furthermore, Virtual Private Networks and dial-in software are not generic. For example, they do not provide a solution when two portable devices accessing the Internet via a wireless modem want to communicate with one another. Thus, it is not uncommon to have a scenario wherein neither the system within the enterprise network can initiate communication with the external personal device nor can the external personal device initiate communication with the system within the enterprise network.
A number of techniques have been proposed or suggested to permit communications between an external device and a system within an enterprise network. Visto Corporation, for example, employs holes in firewalls to make outgoing connections to portable devices. A similar approach is described in B. Biggs, “SIP Application Level Gateway for Network Address Translation,” Internet Engineering Task Force (IETF), Internet Draft (March, 2000). It is not always possible, however, to create a hole in a firewall, and in any case, such a solution is not a general one (as it requires special firewall support). Even when a firewall does allow the creation of such holes, firewall administrators are often reluctant to create such holes for user applications, since any hole in a firewall makes the enterprise system vulnerable to an attack.
Portable devices are increasingly establishing communications in accordance with the Session Initiation Protocol (SIP), described, for example, in M. Handley et al., “SIP: Session Initiation Protocol,” RFC 2543 (March 1999). Generally, SIP is an application level protocol used to establish multimedia sessions between two or more systems. The SIP community is pursuing two types of solutions to permit communications between an external device and a system within an enterprise network. A first approach advocates making the firewalls or network address translators SIP-aware and a second approach advocates making SIP firewall/network address translator-friendly.
The SIP community pursuing the first approach is working to specify an application program interface (API) that allows applications, including SIP applications, to request the specific kind of support they need from the firewall. For example, applications might request that the firewall provide an external address and port number for the application to receive incoming TCP requests or UDP messages. Specifying this API, and therefore making firewalls and NATs SIP-aware, is part of the task of the Middlebox Communication (MIDCOM) Working Group of the IETF. A MIDCOM solution faces multiple obstacles. Specifically, agreement must first be reached on the protocol, vendors must thereafter implement the protocol in their products, enterprises must purchase the new products, and firewall administrators must permit the use of these features.
The second approach was proposed by Rosenberg, Weinberger and Schulzrinne. See, J. Rosenberg and H. Schulzrinne, “SIP Traversal Through Residential and Enterprise NATs and Firewalls,” Internet Engineering Task Force, Internet Draft (Mar. 2, 2001), further revised in “NAT Friendly SIP,” Internet Engineering Task Force, Internet Draft (Jul. 20, 2001). With respect to NATs, Rosenberg et al. propose to enhance the SIP user agents to engage in a test regime with multiple new kinds of test facilitator servers on the external network to identify the type of NAT that exists between the user agent and the external network. The user agent has the burden of testing for NAT-type. Generally, Rosenberg et al. propose disguising the traffic as web traffic so that it will be passed by the firewall.
The restrictions of NATs and firewalls create an environment where it is often difficult for employees with portable devices, users in different enterprises, employees at home and other users to communicate with systems within an enterprise. A need therefore exists for a method and apparatus that supports communications between a computing system within a protected network and an external computing system, such as a portable device. A further need exists for a method and apparatus that supports secure communication between portable devices and systems within an enterprise or another network.